一份可以同时满足传统与互联网业务的Dev平台攻略
作者介绍
胥建英，拥有八年云计算领域、云自动化运维、DevOps及微服务建设经验。
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
本篇主要讲的是Dev环节的支撑平台。一套Dev平台如何同时支持传统企业交付模式以及互联网业务交付模式。关于支撑Ops阶段的平台涉及内容庞大复杂，后续会从数据中心Ops的角度展开论述。
关于本人对Dev与Ops环节的支撑平台的划分，大致为如下：
一、场景分析
互联网业务的特点是自开发、自运维，标准的Devops模式。从研发活动来看，涉及五个阶段：Code，Build，Test，Deploy，Monitor。每个阶段的职责不同。
传统IT业务的特点是研发团队负责开发交付，IT技术支持团队负责实施（部署、升级），客户负责运维，且传统IT企业交付的往往是一整套完整的解决方案。
相比较互联网业务模式，研发活动流程变成如下，增加了Assemble（装配过程）：
也就是如何将开发团队的输出装配为面向客户交付的解决方案包。
两种场景下的共同诉求都是Devops理念中构建、测试，发布更加快捷、频繁、可靠。
核心目标是如何快速、低门槛地开发，同时对于QA来说，是要解决如何进行统计度量（代码量、产出率等）的问题。
快速、低门槛让开发尽可能只聚焦于核心业务逻辑的实现，更多的工程相关的属性依托于可视化、自动化的构筑生成。因此需要契约化的工程结构，以支撑后续的运行维护管理。
微服务架构模式下，微服务是最小的工程单元，因此也就是定义一种符合微服务的契约化的工程属性。微服务的特征要求具备独立可编译部署变更，对外需要清晰的API等。
因此可以定义譬如下面的开发工程的目录结构：
一般一个微服务的开发顺序可参照如下：
一般在设计阶段就需要输出API定义，传统的往往是Word或者Excel等定义，用于评审，然后开发阶段需要编写代码去定义，此部分则可以完全简化，基于YAML/JSON定义API文件，并基于Swagger直接可视化展示API用于评审，开发阶段同样基于此文件直接生成API代码和到业务逻辑的调用。最终开发者直接编写API的实现单元即可。
依托于契约化松耦合的目录结构，需要Devops平台具备如下的能力：
微服务的初始化管理服务。微服务自身就是个后续需要被维护管理的对象，故而需要一个微服务管理的能力。包含：微服务定义，开发工程生成，以及关键指标的搜集（代码量、开发语言、责任人、提交次数等）。
基于主流开发工具（Eclipse、IDEA）可一键式生成API代码。
微服务初始化管理服务（后续简称Codeinit）结构可大致表述为如下:
至此基于微服务管理服务的Code过程变为：
核心目标是检查原始代码的质量并编译生成可执行的包。
下载代码：是指从代码仓库下载到编译服务器；
门禁检查：包含契约化目录规范的检查，圈复杂度检查，FindBugs检查，代码样式检查等；
编译：则是将原始代码生成二进制，使用语言自身的编译器完成，打包则是生成预期的最终可部署的包，其包含编译产生的二进制文件以及程序的配置文件等；
推送：是指生成的包推送到包仓库（FTP服务器、镜像库等）；
统计：贯穿在整个Build阶段，是指Build阶段的各种度量指标，譬如编译次数、编译成功率等。
Assemble核心目标是微服务包到服务包，服务包到解决方案大包，或者微服务包到解决方案大包的自动化装配过程。需要一种契约化的包的装配规则的定义，包含目标包类型（解决方案、服务），包含服务或者微服务。最终客户拿到的是一个基于部署系统可部署的完整的大包，不用自己手动下载组装配套的多个包。
最终效果：研发团队视角提供微服务，形成一种原子能力的微服务池子，不同解决方案定义不同的微服务打包策略，基于Devops平台自动装配不同的解决方案包。
Deploy阶段隶属于Ops范围，涉及上下内容很多，后续详细展开论述，此部分只做概要介绍。
部署系统的核心目标是可视化/自动化地将解决方案包/服务包/微服务包部署到不同的环境的节点上。这里面涉及几个名词：包、部署动作、环境、节点，需要展开论述：
包：指的是开发活动交付的软件的载体，可以是ZIP/镜像等。
环境：指的是部署活动中涉及的Alpha （服务内自验证环境），Beta（服务间联调环境），Gamma（类生产环境），Product（生产环境）。
节点：这里面定义的是在可直接部署包的介质，需要强调的是可直接部署性。一般性硬件和软件是分离的两拨人，一个数据中心内允许两次驻场：设备采购到位后，硬件调测人员进驻进行硬件安装配置；其次是软件调测人员驻场，进行操作系统安装及其之后的过程。
而对于部署系统来说，此处部署的是软件包，并不包括OS安装配置，故而也就引出了另一个系统：独立的装机服务，此即为部署系统的其中一个上下文，但并非属于部署系统。但是实际往往也没有独立的装机服务，譬如节点如果全是虚拟机，而一般企业虚拟机的生命周期管理往往存在于独立的云管理平台中（物理机的初始化、OS安装、虚拟机发放）。此时云管理平台即可承载此处所需的装机能力。
DevOps模式下的Monitor隶属于Ops范围，涉及内容和上下文很多，其内容包含监控（硬件、OS、业务的性能、调用链、拨测），告警和故障诊断等，上下文涉及变更、事件、报表、通道等后续展开论述。
此处需要附加说明的是即使从Dev阶段也是需要Monitor能力的，也就是监控统计Code、Build、Assemble阶段的各个指标。
二、Dev平台技术调研分析
分析目标：基于上述Dev平台建设思路，Docker的目标在此处位于Build或Assemble阶段场景之一，也就是流水线环节中构建包（镜像），所以重点分析的是Docker镜像库及构建镜像的环节。但是不仅限于Docker，需要扩展分析支持带状态应用的下的容器技术（类似虚拟机形态的面向资源的容器的镜像模型和构建）。
分析目标：基于上述Dev（Ops）平台建设思路，Kubernates的目标在于Deploy阶段使用场景之一，也就是流水线环节中部署系统，重点分析基于Kubernates部署应用的流程、运行机制和部署架构。
分析目标：基于上述Dev平台建设思路，Jekins的目标是自动化Code到Build或者Assemble阶段，重点分析其使用流程，Jekins的扩展性（譬如插件生态、二次开发能力等），用于决策整个Code->Assemble阶段是自研借鉴或者还是基于其二次开发。
分析目标：基于上述Dev平台建设思路，Gerrit的目标是Code阶段的代码Review，重点分析其使用方式（操作和角色权限控制）和环境部署，用于集成到整个Dev流水线之中。
分析目标：基于上述Dev平台建设思路，此处主要是提供代码仓库，需要重点分析其使用方式、API（或Lib库）等，同时横向需要比较分析Gitlab，已决定采取何种构建代码仓库。
以上是关于Dev环节的支撑平台的概述，后续将从数据中心Ops的角度展开讲支撑Ops阶段的平台，欢迎大家留言交流。
近期热文
PPT下载 | 2018 Gdevops峰会广州站火爆收官！